Numerous tools have been developed to aid in network management involving capacity planning, fault management, network monitoring, and performance measurement. One example of such tools is the network analyzer.
In general, a “network analyzer” is a program that monitors and analyzes network communications, detecting bottlenecks and problems. Using this information, a network manager can keep communications flowing efficiently. A network analyzer may also be used to capture data being transmitted on a network. The term “network analyzer” may further be used to describe a program that analyzes data other than network communications, or may also be used to classify packets into flows. For example, a database can be analyzed for certain kinds of duplication, etc. One specific example of a network analyzer is the SNIFFER® network analyzer manufactured by NETWORK ASSOCIATES, INC®.
Prior Art FIG. 1A illustrates a network analyzer 10, in accordance with the prior art. Such network analyzer 10 produces protocol decodes and allows application and response time monitoring for the purpose of solving network problems, etc. To accomplish this, the network analyzer 10 includes a sequencing and reassembly (SAR) module 12 for sequencing and reassembling frames of gathered network communications.
The basis for the SAR module 12 may be an architectural model involving a flow database. The flow database records data flows from network connections at each layer of the open systems interconnection (OSI) model upon which most protocols depend or may be mapped. For example, connections between two network interface cards (NIC) (physical layer) are components of the flow database. The network topology determines the data link control layer (DLC), which is also registered in the flow database. On top of the DLC layer is the network layer (e.g., IP), which also contributes to the flow database. This model continues up the protocol stack to the application layer, where protocols such as Sybase/Microsoft® SQL Server, Oracle® SQL Server, HTTP, etc. may be found.
Coupled to the SAR module 12 is a suite of a plurality of protocol interpreter modules 14. The protocol interpreter modules 14 are adapted for interpreting or translating protocol frames for the purpose of being sequenced and reassembled by the SAR module 12. Often such protocol interpreter modules 14 are typically added to the SAR module 12 to handle desired protocols. It should be noted that the protocol interpreter modules 14 may be selectively disabled/enabled as needed in a given situation.
Each of the protocol interpreter modules 14 further includes a registration module 15. Upon initiation of the network analyzer 10, each registration module 15 registers the associated protocol interpreter modules 14 in the suite and indicates to the SAR module 12 how the corresponding protocol should be reassembled, etc.
In use, the network analyzer 10 must be able to identify the particular protocols associated with gathered network communications so that the appropriate analysis may be carried out. Many familiar protocols are transported over transmission control protocol/internet protocol (TCP/IP) using what are known as “well-known” port numbers, or “registered” port numbers. Traditionally, a port number is a field in a TCP header. Other protocols, such as Oracle®, Sybase® and Microsoft® SQL database servers are not necessarily on well-known or registered ports. Instead, these protocols may appear on what are known as “dynamic” port numbers. The solution to the problem of identifying a protocol when known protocols are run on unfamiliar ports or use dynamic ports is a process of heuristics.
Such heuristics often employ various aspects of network communications. For example, many dynamic port protocols have well-defined headers preceding the data portion of a protocol data unit (PDU). Prior Art FIG. 1B illustrates an exemplary header 20 with which typical packets start. As shown, the header 20 may include a packet type field 22, last packet indicator 24 field, packet size field 26, channel field 28, packet number field 30, and a window field 32. In use, the PDU is transported from an end user computer to a server computer in the form of one or more request packets. Such PDU is further transported from the server computer to the end user computer in the form of one or more reply packets.
To heuristically determine if the protocol in a given packet is in a particular format [i.e. tabular data stream (TDS)], the network analyzer 10 may examine the header 20 as well as apply other knowledge about the protocol for protocol decoding. For example, the network analyzer 10 may validate that the packet type is within a specified range, and/or the packet size is appropriate for the particular format. Other tests may be conducted depending on the packet type, last packet indicator, and other fields as necessary. The foregoing analysis may return a TRUE response if the packet can be identified as TDS, or a FALSE response otherwise.
Typically, the foregoing heuristic techniques are carried out by a heuristic module 13 which is resident in the SAR module 12. Unfortunately, such framework has many drawbacks.
By way of example, when a particular protocol interpreter module 14 is disabled in the aforementioned manner, the heuristic module 13 still does any associated heuristic tests. This unnecessary processing results in decreased performance.
Moreover, when additional protocol interpreter modules 14 are coupled to the SAR module 12 and additional heuristic techniques are required, significant reworking of the SAR module 12 and the associated heuristic module 13 is required. Therefore, such prior art network analyzer 10 simply lacks any type of modularity and/or portability.
There is thus a need for a network analyzer which overcomes these and other shortcomings in the prior art.